home *** CD-ROM | disk | FTP | other *** search
/ Aminet 22 / Aminet 22 (1997)(GTI - Schatztruhe)[!][Dec 1997].iso / Aminet / hard / drivr / vbak2091.readme < prev   
Text File  |  1997-11-02  |  14KB  |  312 lines
  1. Short:    Makes A2091 work in A4000. V1.4 (8.10.97)
  2. Author:   Volker Barthelmann, Andreas R. Kleinert
  3. Uploader: Andreas_Kleinert@t-online.de
  4. Type:     hard/drivr
  5.  
  6.  
  7.     *** see "history.txt" for a list of recent changes ***
  8.  
  9.  
  10.     vb2091 (vbak2091) V1.4 (8.10.97)
  11.  
  12.     (c) in 1994 by Volker Barthelmann
  13.     modified 1996-97 by Andreas R. Kleinert,
  14.  
  15.     USAGE AT YOUR OWN RISK. NOBODY CAN BE HELD RESPONSIBLE FOR ANY DAMAGES.
  16.  
  17.  
  18. PREFACE
  19.  
  20.     [ Andreas: ] Since I had some problems with the A2091 in my
  21.                  A4000 and saw room for some optimizations in vb2091,
  22.                  I decided to write something like "vbak2091" and
  23.                  contacted Volker to take a look at the resulting
  24.                  source. I've now been testing the current SAS/C compiled
  25.                  version for about 2 months and did not encounter many problems,
  26.                  and decided to do a final release, where Volker did the final
  27.                  adjustments for his VBCC compiler. GCC should work, too.
  28.  
  29.                  -------------------------------------------------------------
  30.                  When running vbak2091 it may make sense to install
  31.                  the following programs (in this order), too:
  32.  
  33.                     C:FastExec NOEXEC FASTSSP FASTVBR FASTEXP FASTMEM FASTINT REBOOT
  34.                     C:LoadV43Module c:a1000.ld.strip REBOOT
  35.                     C:SetPatch QUIET
  36.                     Run C:MapBoard A2091
  37.                     Run C:vbak2091 [OPTIONS]
  38.                     C:NSDPatch PCF DEVS:NSDPatch.cfg QUIET
  39.  
  40.                  Note the following:
  41.  
  42.                   - all programs should be called as "[command] >NIL: <NIL:"
  43.                     or "Run >NIL: <NIL: [command]" (has been shortened above).
  44.                   - FastExec is recommended (Aminet).
  45.                   - LoadV43Module (and the scsi.device V43 patch strip) can
  46.                     be found on ftp.amiga.de (Beta).
  47.                   - SetPatch V43 is recommended. Can be found on ftp.amiga.de (Beta)
  48.                   - you have to supply additional options for "vbak2091" (see below)
  49.                   - MapBoard can be found on Aminet. It will drastically increase
  50.                     the speed that can be reached in conjunction with vbak2091
  51.                   - NSDPatch turns the old A2091 scsi.device V37.x into a 'new style'
  52.                     device and thus should be installed *after* vbak2091.
  53.                     Can be found on ftp.amiga.de (Unsupported).
  54.                   - you may also wish to install the newest FastFileSystem V43 beta
  55.                     version on the related hard disk partitions.
  56.                     Can be found on ftp.amiga.de (Beta)
  57.  
  58.                  The above configuration basically worked for me - you have to
  59.                  test for yourself whether the newest versions of the concerned
  60.                  tools will work as well with your system configuration.
  61.                  Remember: there's no guarantee given for anything...
  62.                  -------------------------------------------------------------
  63.  
  64.                  Included you find the compiled SAS/C version (vbak2091),
  65.                  the SAS/C, GCC and VBCC-aware source code (vbak2091.c)
  66.                  and the original source code of the last public Aminet
  67.                  release (vb2091.c).
  68.  
  69.                  So you can easily see, what the program is doing.
  70.  
  71.                  Feel free to modify and improve the source code,
  72.                  but tell us before releasing it !
  73.  
  74.                  Neither me nor Volker will take any responsibility
  75.                  for any results out of the usage of this program;
  76.                  neither for any damages nor any loss of data, nor
  77.                  anything else. It's your own risk!
  78.  
  79.                  Enjoy :-)
  80.  
  81.                  Andreas R. Kleinert <Andreas_Kleinert@t-online.de>
  82.  
  83.  
  84.                  Following is the original documentation, speaking
  85.                  is [ Volker: ]
  86.  
  87. INTRODUCTION
  88.  
  89.     ZorroII boards can only reach the lower 16MB of address space. So DMA
  90.     SCSI controllers must find another way to transfer data to expansion
  91.     RAM. Some of them (especially the A2091) do a very bad job in this
  92.     situation. In an A4000/40 transfer rates may drop to 50KB/s.
  93.     This program patches the (2nd.)scsi.device to use MEMF_24BITDMA
  94.     RAM as a buffer followed (in case of CMD_READ) by CopyMem().
  95.     It was developed with the A4000/A2091 combinbation in mind, but
  96.     should work with other configurations, too (see REQUIREMENTS). Some
  97.     people reported good results with GVP controllers.
  98.  
  99.     There have been some bugfixes, additional options and changes of the
  100.     commandline options since the last public release. So I am afraid all
  101.     users of previous versions will have to read this manual again
  102.     (especially the USAGE section).
  103.  
  104.  
  105. FEATURES
  106.  
  107.     There are already some PD utilities floating around that do a similar
  108.     job. So why may this one be better?
  109.  
  110.     - It patches the device instead of the Read() & Write() DOS-functions,
  111.       giving the following advantages:
  112.  
  113.       o Programs accessing the device directly (e.g. SysInfo, SCSI-Speed
  114.         or tape-handlers) are patched, too.
  115.       o Patching Read() doesn't seem to have any influence on LoadSeg(), so
  116.         those patches don't speedup loading of programs whereas vb2091 does.
  117.       o It is possible to use double-buffering and load into one buffer
  118.         while copying the contents of the other one to fastram. This makes
  119.         higher transfer rates possible. I wasn't able to get more than
  120.         800KB/s with DOS-level-patches, but could get over 1MB/s with
  121.         vb2091.
  122.  
  123.     - Some early A4000s (including mine :-( ) can't do DMA to onboard ram.
  124.       On such A4000s every transfer to/from chipmem will cause the
  125.       computer to hang. vb2091 can be told to redirect those transfers too.
  126.  
  127. WARNING
  128.  
  129.     FIRST: READ THIS ENTIRE FILE BEFORE TRYING OUT vb2091 !!
  130.     (This is meant seriously - I know this is a very badly written manual,
  131.     but it mentions some very important points.)
  132.  
  133.     This program is still beta and I can't give any warranty about anything.
  134.     I have tested it for some time and have not encountered serious
  135.     problems, but had no opportunity to test vb2091 on other configs,
  136.     so there may still be many bugs.
  137.     It seems to work fine with my system (A4000/40, broken DMA, A2091/7.0
  138.     ROMs, Quantum LPS270S+LT730, Tandberg streamer) in conjunction with
  139.     MapBoard, however there may be problems with the serial port.
  140.  
  141. REQUIREMENTS
  142.  
  143.     vb2091 has been compiled with gcc, so it needs ixemul.library in libs:
  144.     and ENV: assigned. Keep this in mind when placing it in Your startup-
  145.     sequence. There will probably be a version that has been compiled with SAS
  146.     in this distribution. This version doesn't have these requirements.
  147.  
  148.     As it uses the exec-functions CopyMem()/CacheControl(), it doesn't work
  149.     with early versions of Kickstart (sorry, I don't know since when these
  150.     functions are present - probably since 2.0).
  151.     vb2091 does not check for a correct version at the moment (sorry).
  152.  
  153.     You must have some MEMF_24BITDMA RAM (e.g. RAM on the controller or
  154.     chipmem) to be used as a buffer.
  155.  
  156.     I hope I haven't forgotten anything (of course a controller and some
  157.     expansion RAM would be quite useful).
  158.  
  159.  
  160. USAGE
  161.  
  162.     [run] vb2091 UNIT <unitlist> [DEVICE <device>] [BUFSIZE <bufsize>]
  163.                  [MAXN <number>] [MIN1BUF <size>] [MIN2BUF <size>]
  164.                  [BROKEN] [SINGLE] [NOCACHE] [NOWRITE]
  165.  
  166.     All the keywords must be uppercase! (sorry)
  167.  
  168.     UNIT    List of unitnumbers of devices to be patched, not separated by
  169.             spaces or commas, e.g. 014 for device 0, 1 and 4.
  170.             (default: no default - this MUST be specified)
  171.  
  172.     DEVICE  Name of the device to be patched.
  173.             (default: 2nd.scsi.device)
  174.  
  175.     BUFSIZE Size of buffer in kilobytes.
  176.             (default: 256)
  177.  
  178.     BROKEN  Use this if You have got an A4000 that cannot DMA the chipmem.
  179.             You MUST have some 24Bit fastmem (e.g. on the controller)
  180.             then - vb2091 will only accept MEMF_FAST|MEMF_24BITDMA RAM
  181.             as buffer then.
  182.  
  183.     SINGLE  Normally vb2091 uses double-buffering to get slightly higher
  184.             transfer rates; use SINGLE, if free processor time is more
  185.             important to You. Currently only CMD_READ is double-buffered,
  186.             CMD_WRITE is not.
  187.  
  188.     NOWRITE If You specify this option, only CMD_READ ist patched, whereas
  189.             CMD_WRITE will be unchanged. Use this if You don't trust
  190.             vb2091.
  191.  
  192.     NOCACHE If this option is specified, the DataCache will be disabled
  193.             before CopyMem() and enabled after finishing; this will speedup
  194.             CopyMem() (at least on a 040). This has not been tested very
  195.             well, so be careful with this option.
  196.  
  197.     MAXN    <number> (default: 16)
  198.     MIN1BUF <size in kilobytes> (default: 128)
  199.     MIN2BUF <size in kilobytes> (default: 64)
  200.             These options can be used to adjust some parameters which are
  201.             used with double buffering. If a block of size l is to be read
  202.             then vb2091 will probably split the transfer into smaller blocks
  203.             for better use of double buffering. If l<MIN1BUF then vb2091
  204.             will use one transfer of l bytes (i.e. no double buffering), if
  205.             possible. If l>MAXN*MIN2BUF then the transfer will be split into
  206.             MAXN parts. If none of those conditions is true then the transfer
  207.             will be split into blocks of size MIN2BUF.
  208.             I thought about a rather simple method to let the user adjust the
  209.             buffers in different situations without having to specify one
  210.             BUFSIZE for almost every single transfer size. The method I used is
  211.             just heuristic and the default values were chosen rather arbitrary
  212.             and optimal values may be quite different (especially on different
  213.             systems). MIN2BUF shall be set to the smallest size which achieves
  214.             good transfer speeds with little cpu usage. So MIN2BUF is the value
  215.             which should usually be used as buffer size (yielding high rates
  216.             and as many chunks, i.e. best use of double buffering, as possible).
  217.             But if the transfer size is a little larger than MIN2BUF, it
  218.             wouldn't be a good idea to usee double buffering with those chunks.
  219.             E.g. with MIN2BUF=64k a 65k transfer would be split up in a 64k
  220.             transfer and a 1k transfer. Although I haven't tested it, one 65k
  221.             transfer should be better. Because of this You can prevent double
  222.             buffering for any transfers less than MIN1BUF. I set
  223.             MIN1BUF=2*MIN2BUF for default, but this may be too large.
  224.             Now if You have very large transfers (e.g. 4MB), then it would be
  225.             split up into 64 64k chunks. But from a certain number of chunks it
  226.             should be better not to raise the number of chunks but the size of
  227.             the chunks (especially as MIN2BUF should be set as small as
  228.             possible). This is what MAXN is for - however this is rather
  229.             theoretical, because I doubt that transfers that large will occur
  230.             often (if at all).
  231.             As said before this method can be argued (especially as I almost
  232.             haven't tested if my thoughts are true in reality) and the default
  233.             values may be far from optimal. So everybody who wants almost
  234.             optimal performance has to find out his personal values (they also
  235.             depend on the applications You use, because You can configure
  236.             vb2091 for best speed or least cpu usage or something inbetween).
  237.  
  238.  
  239.     Example:
  240.         run >NIL: vb2091 DEVICE scsi.device BUFSIZE 128 MAXN 8 UNIT 046
  241.  
  242.  
  243.     You can remove the patch by sending vb2091 a CTRL-C/break - but don't
  244.     do this while any program is using the device.
  245.  
  246.  
  247. SOURCE
  248.  
  249.     I decided to distribute the source in order to raise chances of finding
  250.     bugs. You should be able to compile it using gcc (I used 2.3.3) or SAS.
  251.     It is NOT meant to be an example of good programming and I am not liable
  252.     for anyone turning into stone after looking at it.
  253.  
  254.  
  255. CREDITS
  256.  
  257.     This program would not exist without the help of Olaf Seibert (another
  258.     poor fellow with a broken A4000) who encouraged me to write it and
  259.     provided me with helpful information. Thank You, Olaf!
  260.     Thomas Boerkel did the changes for SAS and compiled it.
  261.     Several testers helped to remove some bugs of the older versions and made
  262.     suggestions for improvement.
  263.  
  264. LEGAL
  265.  
  266.     vb2091 may be freely distributed as long as no part of the distribution
  267.     is changed.
  268.  
  269.     This program is Bearware: If You like it, You can send me something
  270.                               with a bear on it.
  271.  
  272.     But more important:
  273.  
  274.         If You try it, please send me Your experiences, bugreports,
  275.         suggestions etc.
  276.  
  277.  
  278.  
  279.  
  280. Volker Barthelmann
  281. Kennedy-Ring 39
  282. 91301 Forchheim
  283. Germany
  284.  
  285. I should be reachable per eMail via:
  286.  
  287. volker@vb.franken.de
  288.  
  289.  
  290. ============================= Archive contents =============================
  291.  
  292. Original  Packed Ratio    Date     Time    Name
  293. -------- ------- ----- --------- --------  -------------
  294.     3809    1234 67.6% 13-Aug-97 14:28:02  compiler.h
  295.     9131    2497 72.6% 13-Aug-97 14:25:14  vb2091.c
  296.      835     392 53.0% 13-Aug-97 14:25:56  vbak2091.info
  297.      206     143 30.5% 14-Sep-97 13:21:02  scoptions
  298.      177      87 50.8% 14-Sep-97 13:20:00  smakefile
  299.       79      73  7.5% 14-Sep-97 13:21:08  smakefile.wth
  300.      194     102 47.4% 14-Sep-97 13:21:52  smakefile040
  301.       86      78  9.3% 14-Sep-97 13:21:14  smakefile040.wth
  302.     6056    3843 36.5% 14-Sep-97 13:22:22  vbak2091
  303.     6212    3926 36.7% 14-Sep-97 13:21:56  vbak2091.040
  304.      835     388 53.5% 14-Sep-97 13:21:56  vbak2091.040.info
  305.    15849    3970 74.9% 14-Sep-97 13:17:04  vbak2091.c
  306.     4536    2748 39.4% 14-Sep-97 13:22:20  vbak2091.o
  307.     4536    2754 39.2% 14-Sep-97 13:20:20  vbak2091040.o
  308.      652     319 51.0% 08-Oct-97 18:12:02  history.txt
  309.    13125    5330 59.3% 08-Oct-97 18:13:08  vbak2091.readme
  310. -------- ------- ----- --------- --------
  311.    66318   27884 57.9% 08-Oct-97 23:01:18   16 files
  312.